r? @compiler-errors

rustbot has assigned @compiler-errors.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

r? compiler

I changed this part last year, will review this PR later.

r? @chenyukang

I think this solution introduces some kind of regression on other scenarios(such as the cases I commented).

Maybe we should consider this as a special corner case and provide a special diagnostic for it, it is the pattern that one delimiter is missing the openning delimiter(it's in the inner part), except for this everything is ok, so we should suggest something like "missing openning delimiter ....".

such as:

{ ... {. ) ... }...} missing a inner (
{ ... [ ], ] ...} missing a inner [

@rustbot author

Reminder, once the PR becomes ready for a review, use @rustbot ready.

Thanks, I will revise it soon!

This seems like quite a lot of changes, I'll comment in the code to make it easier to REVIEW.

In the first commit, I added the test.

In the second commit I did some clean. I changed a variable name, the original name was inaccurate, I used open_delimiters instead of open_braces for identifying blocks, one should compare spans, not just brace'{'.

In the third commit, I make a distinction between the different delimiters before triggering a unexpected closing delimiter error. But I found that missing open delim note is what triggers in unexpected closing delimiter error.
Therefore, to emit missing open delim note, I also moved missing open delim note to
mismatched closing delimiter error, which can be emitted without delaying to
unexpected closing delimiter error.
And I moved function make_unclosed_delims_error
to src/lexer/diagnostics.rs for clean. And some other clean.

I've combined them into one line so it's more aesthetically pleasing.

mismatched closing delimiter, may missing open `(`

Since the mismatched closing delimiter note and the unclosed delimiter note are related, it may be the better to keep it.

For this comment #138554 (comment)

Unfortually, <...> is not recognized as delimiters1, So the pattern here should be ()), the current state is reasonable.

As to why the <... > is set to delimiter, I think it's due to syntax like a>b and thus not parsed here. For example, encountering places where generic arguments should exist, and then recursively descending to parse <... >.

For this comment #138554 (comment)

Unfortually, <...> is not recognized as delimiters1, So the pattern here should be ()), the current state is reasonable.

As to why the <... > is set to delimiter, I think it's due to syntax like a>b and thus not parsed here. For example, encountering places where generic arguments should exist, and then recursively descending to parse <... >.

got it, thanks for the explanation.

I don't have other questions except for #138554 (comment)

seems the latest commit #138554 add more noise.

0682e9e is good enough.

This commit 0682e9e is for #138554 (comment). I use the nearest open delimiter.

The last commit a1d2557 is for comment #138554 (comment). In all the cases, we should emit missing open delimiter hints. Because,

1. In mismatched error exists, the hint is not concrete enough.
2. In mismatched error removed, the hint is then naturally needed.

Now, all the changes is

1. Add a nearest open delimeter label in missing open delimeter hints
2. remove false mismatched error in the cases like {}}

That's all we need.

But the code needs some clean. If everything is Ok, I will clean the code and squash commits. 😃

seems the latest commit #138554 add more noise.

The last commit is necessary if one is in a conservative consideration, as #138401 seems to be just to address cases like, {}}. The exact explanation is in my last comment #138554 (comment).

#138554 (comment)

I think we can remove those hint, since we reported mismatch above.

Ok, I'll revise it later.

But I have a concern that we only reported what went wrong in the mismatched error, but we didn't mention how to correct it. I think this hint complements this.

If you think it should be removed, I will remove the last commit later.

But I have a concern that we only reported what went wrong in the mismatched error, but we didn't mention how to correct it. I think this hint complements this.

If you think it should be removed, I will remove the last commit later.

for a mismatched scenario, the hint is not complementing it:

{ .... ] may be fixed as { ..... } or [ .... ].

perfer to remove it.

Make sense! I removed it.

And I cleaned the code, and squashed them to 2 commits. Now, it should be what we want!

Thanks!

@bors r=chenyukang

📌 Commit 181c1bd has been approved by chenyukang

It is now in the queue for this repository.

Thank you for your patient guidance! ：）